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DETAILED ACTION 

1 . The Office Action is responsive to the communication filed on 06/03/2009. 

2. Claims 1-2, 4-5, 8-13, 15-19, 21-26, 28-30, 32, 34-40, 41-42, and 44-49 are pending. 

Continued Examination Under 37 CFR 1.114 

3. A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1 . 1 7(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.1 14. Applicant's submission filed on 06/03/2009 has been entered. 

Information Disclosure Statement 

3. The information disclosure statement (IDS) submitted on 06/03/09 is in compliance with 
the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being 
considered by the examiner. 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
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having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

5. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 
(1966), that are applied for establishing a background for determining obviousness under 35 
U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness 
or nonobviousness. 

6. Claims 1-5, 8-14, 28-32, 34-40, and 45-47 rejected under 35 U.S.C. 103(a) as being 
unpatentable over Melpignano et al. (USPN 2006/0084417 Al) in view of Shi (USPN 6807163), 
and in further view over Nguyen (USPN 20030212784) 

7. As per claim 1, Melpignano et al. teaches a computing system supporting network 
selection based upon network information spanning multiple communication media, the system 
comprising: 

a rules data store ([0049], [FIG 3 - network interface 'if class diagrams] e.g., rules data store 
is interpreted as maintaining selection criteria) for maintaining network selection criteria ([0049- 
52], [0035] e.g., location, context class, Networklnterface class (priorities), user preferences, 
speed, power consumption, mobility profiles, cached information, security, and connection costs) 
acquired from a plurality of sources ([0039], [0049 - suitable main classes of NISP], [FIG 3 - 
elements 200, 202, 210, 214] e.g., plurality of sources, not defined, may comprise multiple 
sources including user preferences, predefined sets or personal policies, and/or classes 
(AccessPoint, Networklnterface, and Context) where each class represents a source of network 
information pertinent to selecting an appropriate interface); 
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a media specific module interface ([0050] e.g., Networklnterface class. It is interpreted that 
this class represents multiple interface types, such as Bluetooth, GPRS, WLAN (e.g., iftype, 
ifName, ifStatus) for providing accumulated network interface information ([Figure 3], [0050 - 
element 202] e.g., accumulate network interface information encompasses type, name, flags, 
physical characteristics per interface) potentially spanning multiple communication media ( e.g., 
Bluetooth, Wlan, GPRS, etc) , the accumulated network interface information being associated 
with a set of networks (e.g., WLAN, WPAN, etc) and a set of network interfaces ([0033 lines 3- 
4], [Figure 3-ifType] e.g., interface cards), each network interface for connecting the computing 
system to a network in the set of networks (e.g., connectivity to server via network); 

a rules engine ([0049-IfManager] e.g., the NicAgent role is implemented by the IfManager 
class) for designating one of the set of networks by applying a network selection criterion from 
the rules data store to the accumulated network interface information potentially spanning 
multiple media ([0053-55] e.g., IfManager takes care of interface connectivity, management, and 
selection being performed by choosing the best interface according to context and user 
preferences. Since the IfManager accesses context, i.e., Context class, the rules engine in effect 
utilizes one or more classes to select the optimal interface) 

However, Melpignano et al. does not teach that the media specific module interface 
comprises a normalization module that standardizes communication requests it receives from the 
rules engine directed to the network interface. Nguyen teaches a network fault monitoring 
module ([0019], [0021], [0027] e.g., A normalization module, in light of applicant's 
specification, is interpreted as providing network status information. Applicant's specification 
teaches that the normalization module standardizes communication via providing status 
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information from the media specific modules to the rules engine. A standard request would be to 
ask for the status and get the status per interface type. It is standard and does not vary per 
interface type. Applicant does not define 'standardization' or what it entails other than a general 
description) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to provide a module to relay the status information from the Networklnterface class 
to the rules engine. Melpignano et al. teaches that the rules engine (e.g., IfManager) 
continuously monitors the network interface availability. Since multiple interfaces are provided, 
it is beneficial to relay the status of each interface to the IfManager such that an appropriate 
interface may be selected. Since a network fault module, as taught by Nguyen, provides 
interface status information to other modules, it would have been obvious to include this module 
as part of the networkinterface class, which illustrates a standard, i.e., interpreted as an 
established form (e.g., request status and provide status) between the rules engine and network 
interface class. 

Melpignano et al. teaches a scanning engine -([Figure 3-element 200 (ImScanning Type) 
associated with a network interface ([0055-56]) for adaptively controlling a scanning delay 
period ([0057] e.g., scanning at periodic intervals.), but does not disclose scanning based at least 
upon results of a previous scan. Shi teaches an adaptive rate channel scanning method for 
adaptively changing the scan rate based on data stored in a channel table during previous 
channels scanned by the channel scan process ([COL 4 lines 30-41) ) (Note: Shi is also 
introduced to address applicant's specification regarding the scan rate and adapting) 
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Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to adaptively change the scan rate based on previous scan results to adapt to changing 
network conditions as a means to save battery power. Melpignano et al. teaches scanning for 
available access points at periodic intervals. Shi teaches changing the scanning rate based on 
previous scan results to conserve battery power. Since adaptively selecting a scan rate as a 
function of network conditions (as assessed via previous scan results) saves power, it would have 
been obvious to modify Melpignano et al. to adapt the scan rate based on previous scans. 

7. As per claim 2, Melpignano et al. teaches the computing system of claim 1 wherein the 
rules engine having has access to the rules data store ([FIG 3], [0054-56]) 

8. As per claim 4, Melpignano et al. teaches the computing system of claim 3 further 
comprising a plurality of media specific modules ([0033] , [0050] e.g., interfaces/associated 
device drivers corresponding to WLAN, WPAN, Bluetooth, IEEE 802.1 lb, i.e., media specific 
interface modules. Page 15 line 7 of applicant's instant specification) configured to acquire 
network interface information ([0050] e.g., fStatus) pertaining to network interfaces associated 
with particular media types, and to receive network interface configuration commands (e.g., 
priority) , from the rules engine, to connect to one of the set of networks ([0053-56]) 

9. As per claim 5, Melpignano et al. teaches the computing system of claim 4 wherein the 
media specific modules acquire network interface information from media specific drivers 
associated with particular network interfaces ([0049-50] e.g., it is understood that interface 
device drivers provide status, capability, and list of reachable access points of the interface card) 
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10. As per claim 8, Melpignano et al. teaches the computing system of claim 1 wherein the 
network selection criterion specifies a preference order between at least two media based upon a 
network parameter associated with the media ([0050] e.g., fPriority) 

11. As per claim 9, Melpignano et al. teaches the computing system of claim 1 wherein the 
network selection criterion specifies a preference order between at least two media based upon a 
network type associated with the media ([0050] fType) 

12. As per claim 10, Melpignano et al. teaches the computing system of claim 1 wherein the 
network selection criterion specifies a preference order based upon a current location of the 
computing system ([0052-56] e.g., location is one criteria employed in selecting an interface) 

13. As per claim 1 1 Melpignano et al. teaches the computing system of claim 1 wherein the 
network selection criterion specifies a preference order between logical networks ([0050] 
fPriority) 

14. As per claim 12, Melpignano et al. teaches the computing system of claim 1 wherein the 
network selection criterion specifies a preference order based upon a network time of use 
parameter ([0051] e.g., 'already been visited') 

15. As per claim 13, Melpignano et al. teaches the computing system of claim 1 wherein the 
rules engine is incorporated into a state machine that cyclically scans a set of network interfaces 
for networks ([0056-57], [FIG 4]), applies the network selection criterion to a set of networks 
and interfaces to render a current network and interface selection ([0053-57]), and issues 
configuration instructions in accordance with the current network and interface selection ([0055- 
57]) 



Application/Control Number: 10/693,655 Page 8 

Art Unit: 2121 

16. As per claim 14, Melpignano et al. teaches the computing system of claim 1 further 
comprising a scanning engine associated with a network interface for controlling the timing of 
scanning based upon previous scan results maintained in a scanning history ([0057], [0061] e.g., 
scanning at periodic intervals. A list, i.e., scan history, of access points is maintained) 

17. As per claim 28, Melpignano et al. teaches a computer-readable medium including 
computer-executable instructions for facilitating selecting a network and interface combination, 
to which a computing system will initiate a connection via the network interface, based upon 
network information spanning multiple communication media, the computer-executable 
instructions facilitating: 

accessing network selection criteria acquired from a plurality of sources ([0039], [0049 - 
suitable main classes of NISP], [FIG 3 -elements 200, 202, 210, 214] e.g., plurality of sources, 
not defined, may comprise multiple sources including user preferences, predefined sets or 
personal policies, and/or classes (AccessPoint, Networklnterface, and Context) where each class 
represents a source of information pertinent to selecting an appropriate interface; 

accumulating network interface information ([0050 - element 202] e.g., plurality of interface 
cards and associated, class information) potentially spanning multiple communication media 
([0033] e.g., data, fax, video, or speech, Wlan, Bluethooth) associated with a set of networks 
(e.g., WLAN, WPAN) and a set of network interfaces ([0033 lines 3-4]), each network interface 
for connecting the computing system to a network in the set of networks (e.g., connectivity to 
server via network), 

However, Melpignano et al. does not teach that the accumulating is facilitated by a 
normalization module that standardizes communication between a set of media specific modules 
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and a rules engine. Nguyen teaches a network fault monitoring module ([0019], [0021], [0027] 
e.g., A normalization module, in light of applicant's specification, is interpreted as providing 
network status information. Applicant's specification teaches that the normalization module 
standardizes communication via providing status information from the media specific modules to 
the rules engine) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to provide a module to relay the status information from the Networklnterface class 
to the IfManager. Melpignano et al. teaches that the rules engine (e.g., IfManager) continuously 
monitors the network interface availability. Since multiple interfaces are provided, it is 
beneficial to accumulate and relay the status of each interface to the IfManager such that an 
appropriate interface may be selected. Since a network fault module, as taught by Nguyen, 
provides interface status information to other modules, it would have been obvious to include 
this module as part of the networkinterface class as part of the standard communication between 
the rules engine and network interface class;); and 

designating, via the rules engine ([0049], [0055]), one of the set of networks and a network 
interface from the set of network interfaces by applying a network selection criterion to the 
network interface information potentially spanning multiple media ([0053-55] e.g., IfManager 
takes care of interface connectivity, management, and selection being performed by choosing the 
best interface according to context and user preferences) 

18. As per claim 29, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion is accessed from a configurable rules data store ([0036] 
e.g. NISP) 
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19. As per claim 30, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the computer-executable instructions further facilitate issuing network interface 
configuration instructions in accordance with the designating step ([0054], [0070-72] e.g., 
connectivity, management, and selection implies that a selected card is configured accordingly. 
For example, insertion/removal of a card entails a new configuration) 

20. As per claim 32, Melpignano et al. teaches the computer-readable medium of claim 3 1 
further comprising computer- executable instructions for acquiring, by the media specific 
modules, network interface information from the communication media drivers associated with 
particular network interfaces ([0049-50] e.g., it is understood that interface device drivers 
provide status, capability, and list of reachable access points for a respective interface) 

21 . As per claim 34, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order between at least two media 
based upon a network parameter associated with the media ([0050] e.g., physical characteristics) 

22. As per claim 35, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order between at least two media 
based upon a network type associated with the media([0050] fType) 

23. As per claim 36, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order based upon a current location 
of the computing system ([0052] e.g., location) 

24. As per claim 37, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order between logical networks 
([0050] e.g. WLAN, WPAN) 



Application/Control Number: 10/693,655 Page 11 

Art Unit: 2121 

25. As per claim 38, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order based upon a network time 
of use parameter ([0051] e.g., 'already been visited') 

26. As per claim 39, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein machine the computer-executable instructions comprises a rules engine for evaluating at 
least one of the network selection criteria based on the accumulated network interface 
information ([0053] e.g., IfManager), and further comprising computer-executable instructions 
for cyclically performing, under the control of a state machine: scanning a set of network 
interfaces for networks ([0057], [FIG 4]); applying, with the rules engine, the network selection 
criterion to a set of networks and interfaces to render a current network and interface selection 
([0054]); and issuing configuration instructions in accordance with the current network and 
interface selection ([0054], [0070-72] e.g., connectivity, management, and selection implies that 
a selected card is configured accordingly. For example, insertion/removal of a card entails a new 
configuration) 

27. As per claim 45, Shi teaches the computing system of claim 1 , wherein the scanning 
engine increases the scanning delay period when the plurality of previous scans indicate there is 
no change in state ([COL 2 lines 1-15], [COL 4 lines 55-60], [COL 4 lines 14-20] e.g., a state 
change is viewed in comparison to the number of LBT channels. One state would be a 
substantial number of LBT channels necessitating minimizing the scan rate. Another state would 
be an indication that the user is in a cell overlap area requiring a higher scan rate) 
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28. As per claim 46, Shi teaches the computing system of claim 1, wherein the scanning 
engine performs a scan when the plurality of previous scans indicate movement of the computing 
system ([COL 1 lines 65-67], [COL 4 lines 35-40]) 

29. As per claim 47, Shi teaches the computing system of claim 46, wherein the scanning 
engine determines the computing system is moving based on at least one of received signal 
strength ([COL 53-65], [COL 6 lines 1-13] e.g., comparison on RSSI values during a handover, 
i.e., movement) , retransmission counts, or frame error rates.) 

30. Claims 15-19, 21-27, and 41-42 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Melpignano et al. (USPN 2006/0084417 Al) in view over Babbar et al. 
(USPN 2004/01 16140 Al) and in view over Shi (USPN 6807163) 

31. As per claim 15, Melpignano et al. teaches a method for selecting a network and interface 
combination, to which a computing system will initiate a connection via the network interface, 
based upon network information spanning multiple communication media, the method 
comprising: 

accessing a network selection criteria acquired from a plurality of sources ([0039], [0049 - 
suitable main classes of NISP], [FIG 3 -elements 200, 202, 210, 214] e.g., plurality of sources, 
not defined, may comprise multiple sources including user preferences, predefined sets or 
personal policies, and/or classes (AccessPoint, Networklnterface, and Context) where each class 
represents a source of information pertinent to selecting an appropriate interface) 

accumulating network interface information ([0050 - element 202] e.g., plurality of interface 
cards and associated, class information, further including status information) potentially 
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spanning multiple communication media ([0033] e.g., data, fax, video, or speech, and/or Wlan, 
bluestooth) , the accumulated network interface information being associated with a set of 
networks (e.g., WLAN, WPAN) and a set of network interfaces ([0033 lines 3-4]), each network 
interface for connecting the computing system to a network in the set of networks (e.g., 
connectivity to server via networks), 

However, Melpignano et al. does not teach that the accumulating is facilitated by a 
normalization module that standardizes communication between a set of media specific modules 
and a rules engine. Nguyen teaches a network fault monitoring module ([0019], [0021], [0027] 
e.g., A normalization module, in light of applicant's specification, is interpreted as providing 
network status information. Applicant's specification teaches that the normalization module 
standardizes communication via providing status information from the media specific modules to 
the rules engine) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to provide a module to relay the status information from the Networklnterface class 
to the IfManager. Melpignano et al. teaches that the rules engine (e.g., IfManager) continuously 
monitors the network interface availability. Since multiple interfaces are provided, it is 
beneficial to accumulate and relay the status of each interface to the IfManager such that an 
appropriate interface may be selected. Since a network fault module, as taught by Nguyen, 
provides interface status information to other modules, it would have been obvious to include 
this module as part of the networkinterface class as part of the standard communication between 
the rules engine and network interface class; and 

designating, via the rules engine ([0049], [0055]), one of the set of networks and a network 
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interface from the set of network interfaces by applying a network selection criterion to the 
network interface information potentially spanning multiple media ([0053-55] e.g., IfManager 
takes care of interface connectivity, management, and selection being performed by choosing the 
best interface according to context and user preferences.) 

However, Melpignano et al. does not teach that network selection criteria is acquired from at 
least one of a group policy service. Babbar et al. teaches a service level agreement ([0009] e.g., 
a group policy is interpreted as an agreement between at least two entities, the agreement 
providing communication rules between the entities. A contract/agreement pertaining to service 
provisioning is a group policy) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to provide a service level agreement as part of the network selection criteria. Babbar 
et al. teaches that mobile users gain access to network services from a terminal. Service level 
agreements provide enhanced access to services, including cost, reliability, priority, protection 
from unauthorized access, and system throughput. Melpignano et al. teaches that network 
selection may be based upon security, costs, data transfer speed, and cached context information. 
In effect, because service level agreements illustrate additional selection criteria, it would have 
been beneficial to acquire network selection criteria, as provided by the service level agreement, 
as part of selecting an optimal network. 

Melpignano et al. teaches initiating network scanning ([0040], [0057], [FIGure 3-element 
200 (ImScanning Type) for a designated one or more set of network interfaces ([0055-56]) 
based at least in part upon a scanning algorithm ([Figure 3-element 200, [0057] ) that adaptively 
changes a scanning frequency ([0057], [0074-75] e.g., scanning frequency is interpreted as how 
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often an entity is checked. Here, an access point may be scanned when a poll interval expires or 
it can be awaked after a new access point wireless event). However, Melpignano et al. does not 
disclose adjusting the frequency based on previous scan results. Shi teaches an adaptive rate 
channel scanning method for adaptively changing the scan rate based on data stored in a channel 
table during previous channels scanned by the channel scan process ([COL 4 lines 30-41) Note: 
Shi is also introduced to address the narrow limitations of the applicant's specification regarding 
the scan rate (should applicant further define 'adapting') 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to adaptively change the scan rate based on previous scan results to adapt to changing 
network conditions as a means to save battery power. Melpignano et al. teaches scanning for 
available access points at periodic intervals. Shi teaches changing the scanning rate based on 
previous scan results to conserve battery power. Since adaptively selecting a scan rate as a 
function of network conditions (as assessed via previous scan results) saves power, it would have 
been obvious to modify Melpignano et al. to adapt the scan rate based on previous scans. 

32. As per claim 16, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion is accessed from a configurable rules data store ([0039] e.g., user preferences 
implies that a user may modify a policy) 

33. As per claim 17, Melpignano et al. teaches the method of claim 15 further comprising 
issuing network interface configuration instructions in accordance with the designating step 
([0039 lines 8-11]) 
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34. As per claim 18, Melpignano et al. teaches the method of claim 15 wherein the media 
specific modules (e.g., Bluetooth, Wlan, etc) are each associated with at least one distinct type 
of communication media driver ([0049] e.g., MWAL handles all drivers for each interface. It is 
implied that there is a unique driver per module, i.e., Bluetooth, Wlan, GPRS, etc) 

35. As per claim 19, Melpignano et al. teaches the method of claim 18 further comprising 
acquiring, by the media specific modules (e.g., interfaces), network interface information from 
the communication media drivers associated with particular network interfaces ([0049-50] e.g., it 
is understood that interface device drivers provide status, capability, and list of reachable access 
points for a respective interface) 

36. As per claim 21, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order between at least two media based upon a network 
parameter associated with the media ([0050] fPriority, [0036] - NISP) 

37. As per claim 22, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order between at least two media based upon a network 
type associated with the media ([0050] fType) 

38. As per claim 23, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order based upon a current location of the computing 
system ([0052] e.g., location) 

39. As per claim 24, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order between logical networks ([0033] e.g., WLAN, 
PWAN], [0050] e.g., fPriority) 
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40. As per claim 25, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order based upon a network time of use parameter 
([0051] e.g., 'already visited or not'). 

41 . As per claim 26, Melpignano et al. teaches the method of claim 15 wherein the 
designating comprises evaluating in a rules engine at least one of the network selection criteria 
based on the accumulated network interface information ([0053-56]), and the method further 
comprises cyclically performing, under the control of a state machine: scanning a set of network 
interfaces for networks ([0057], [FIG 4]); applying, with the rules engine, the network selection 
criterion to a set of networks and interfaces to render a current network and interface selection 
([0054]); and issuing configuration instructions in accordance with the current network and 
interface selection ([0054], [0070-72] e.g., connectivity, management, and selection implies that 
a selected card is configured accordingly. For example, insertion/removal of a card entails a new 
configuration) 

42. As per claim 27, Melpignano et al. teaches the method of claim 15 further comprising 
initiating network scanning for a designated one or more of the set of network interfaces based at 
least in part upon a scanning algorithm ([FIG 3-element 200, ScanningType) and previous scan 
results maintained in a scanning history ([0056-57], [0074-76] e.g., lists of AccessPoints, i.e., 
history) 

43. As per claim 41, Melpignano et al, as modified, teaches wherein the rules data store 
maintains network selection criteria from a plurality of sources ([0039-GUI]) and a group policy 
service (e.g., supra discussion on claim 15 pertaining to service level agreements) 
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44. As per claim 42, Babbar et al. teaches the computing system of claim 41 wherein the 
sources network selection criteria are acquired from include a provisioning service ([0009- 
Quality of Service provisions relating to the delivery of services and content as part of the 
service level agreement) 

45. As per claim 44, Babbar et al. teaches the method of claim 28 wherein the plurality of 
sources of the network selection criteria are acquired from include a provisioning service ([0009- 
([0009- Quality of Service provisions relating to the delivery of services and content as part of 
the service level agreement) 

46. Claim 48 is rejected under 35 U.S.C. 103(a) as being unpatentable over Melpignano et al. 
(USPN 2006/0084417 Al) in view of Shi (USPN 6807163), in view over Nguyen (USPN 
20030212784), and in further view over Hartless et al. (USPN 6292660) 

47. As per claim 48, Hartless et al. teaches the computing system of claim 1, wherein the 
scanning engine ([Figure 3-element 14] e.g., Melpignano et al. also teaches a scanning engine, 
which may be modified to include the functionality of element 14, as per Hartless) is configured 
to detect a network interface to be scanned is sending traffic ([Col 4 lines 4-8], [Col 5 linesl5- 
20] e.g., traffic, i.e., signals, are used to determine motion of the mobile device. It is determined 
that the mobile is sending traffic, i.e., in communication with a site, via analyzing signals. A low 
fade rate would imply that the mobile is not moving but determined to be in communication with 
a site. When it is determined that the mobile is not moving, it is therefore not necessary to scan 
at a particular interval because the mobile is determined to be in communication with a site and 
not moving between sites), the scanning engine analyzes statistics (e.g., a statistic is interpreted 
as a collection of quantitative data, i.e., signal, frequency, velocity, etc ) for the traffic (e.g., 
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signals are processed by equation (1) to provide motion estimate) to determine whether a 
scanning period is to be skipped ([Col 5 lines 4-5] e.g. site scanning is not needed) 

Therefore, at the time the invention was made, it would have been obvious to determine 
that that mobile phone is in communication with a site and not moving to determine whether to 
skip scanning period, i.e., skipping a scan interval. Traffic is analyzed (e.g., analyzing signals, 
which are measured. This measurement(e.g., signal) along with the determined frequency 
provide a collection of quantitative data (e.g., frequency, signal strength, velocity, , i.e., statistics, 
which are used in determining motion). Alternatively, as per Table 1, multiple scan periods are 
depicted. One period may be skipped in lieu of another based on the aforementioned analysis. 

48. Claim 49 is rejected under 35 U.S.C. 103(a) as being unpatentable over Melpignano et 
al. (USPN 2006/0084417 Al) in view of Shi (USPN 6807163), and in view over Nguyen (USPN 
20030212784), and in view over Hawkins (USPN 7025209), and in further view over 
Lemilainen et al. (USPN 6681259) 

49. As per claim 49, Melpignano et al. teaches the computer-readable medium of claim 28, 
further comprising: 

receiving a notification that a new network interface is available ([0070-72] e.g., hardware 
update. It is obvious that interfaces may be added and removed); and 

However, Melpignano et al. does not teach loading another media specific module (e.g. 
network class information. It is obvious to have one class per network interface, providing a 
plurality of classes. One class corresponds to Bluetooth (e.g., type, status), another class 
corresponds to Wlan (e.g. type, status). Each class equates to a module. When a new interface 
is added, a new module is created, as per Hawkins, see below) corresponding to said new 
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network interface,. Hawkins teaches installing a network interface module, i.e., loading a media 
specific module, which would correspond to the new interface hardware, such as Bluetooth, 
where such modules contain code (e.g., drivers) configured to provide network information 
([Col 101 lines 6-14]) 

However, Melpignano et al, as modified (e.g., one class per interface type, where a class is a 
module), does not teach said media specific module (e.g., networkclass) configured to request 
network interface information from a driver for said network interface. Lemilainen et al. 
teaches NIC drivers provide features and state information ([Col 10 lines 1 1-30] e.g., this 
illustrates that drivers provide status information) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to enable the networkinterface class (e.g., module) to request status information using 
network interface drivers. Melpignano et al teaches that interface status is requested - element 
202 (ifStatusFlags). Lemilainen et al. teaches NIC drivers provide status information. 
Therefore, it would have been obvious to use NIC drivers to relay state information to the 
networkinterface module -element 202. As modified, there is a network interface module 
(element 202) for each type of module (e.g., Bluetooth, GPRS, WLan). As new interface cards 
are added, a new module, as per Hawkins, is added to reflect this addition. 

Conclusion 

50. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 
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